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© Data exchange system comprising portable data processing units. 



© Data exchange system comprising at least one 
portable data processing unit (5) comprising data 
communication means (14), processing means (15) 
and memory means (16), the latter comprising an 
executive program (17) and one or more application 
descriptions (18(1) ... 18(n)), each application de- 
scription comprising at least one interaction context 



13(2) 



(19(1) ... ) comprising commands, data elements, 
data references, procedures, access conditions, and 
external references; the structure of the data ele- 
ments and the data references as well as other 
references is chosen in such a way that a very 
efficient use of the restricted memory space of e.g. 
smart cards is obtained. 
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The invention relates to a data exchange sys- 
tem comprising at least one portable data process- 
ing unit comprising data communication means, 
processing means and memory means, the later 
comprising an executive program. 

Such a system is known from the international 
patent application WO-A-87/07063 in which a sys- 
tem for a portable data carrier having multiple 
application files is described. One of the most 
important applications of such a portable data car- 
rier is a smart card suitable for multiple applica- 
tions. The known data carrier is described as a 
carrier of hierarchically structured data with secu- 
rity features to support multiple applications on the 
same data carrier. Applications are seen as sets of 
data. The patent application describes an imple- 
mentation of an hierarchical file system on a data 
carrier to store alterable data in combination with 
an hierarchic set of access permissions. The data 
carrier responds to a set of common commands. 
File access permissions are distinct for different 
operations and granted in dependence on pass- 
word verification. A password verification attempt 
counter is introduced as well as the provision of 
destruction of stored data as sanction against too 
many attempts of access. The known data carrier 
is presented primarily as a storage device and not 
as a processor. Only very simple functions may be 
performed by the executive program such as bi- 
nary logic operation. It is not possible to allow the 
performance of an unspecified set of operations on 
request of a terminal communicating with the data 
carrier. The only security option is the introduction 
of password verification. No other access condition 
verifications are possible within the known system. 
Besides, each application of the data carrier has its 
own file within the memory means of the data 
carrier. No special measures are taken to enhance 
the efficiency of the available memory space 
which, especially on smart cards, is very restrictive 
and therefore sets limits to the number of possible 
applications. 

EP-A-0,479,655 relates to the implementation 
of access condition checks in smart cards. One 
specification technique for that is disclosed, how- 
ever, it is desirable to provide for measures to 
include the possibility of other access condition 
verifications. 

EP-A-0,361,491 relates to a chip card program- 
ming system to allow protected (re)programming of 
cards. It describes the use of write-once-access 
conditions to control access of parts of the prog- 
rammable memory to be programmed. In this way 
the number of applications on a single card can be 
extended. Verification of the access conditions with 
a variety of techniques including cryptographic pro- 
tocols is described. 



EP-A-0,292,248 relates to loading of applica- 
tions on a smart card using an unalterable operat- 
ing system program. It includes the implementation 
of a data access condition enforcement method 
5 using memory zones with assigned access at- 
tributes. Specific access conditions are "write- 
once" (which is only described implicitly) and "ex- 
ecute-only". 

US-A-4,874,935 relates to card programming 

w using a data dictionary where the data dictionary 
describes the layout of data elements stored in the 
card's memory. Data dictionaries are commonly 
understood to differ from directories in that they 
not only describe data actually stored, but also 

75 data which will be stored later. In addition, data 
dictionaries usually include a description of the 
data format. In compiled format data dictionaries 
are used in database management systems where 
they are stored on the hard disc as part of the 

20 database. They are also found in the object load 
files resulting from program compilation in software 
development environments. However, the patent 
does not claim a representation of data dictionaries 
particularly suited for smart cards. 

25 The main object of the present invention is to 

present means to cope optimally with the restric- 
tions imposed by limited physical dimensions of 
available memory space on portable data process- 
ing units, especially smart cards. 

30 A further object of the present invention is to 

offer a more general mechanism of protected load- 
ing of program codes and to allow such a loading 
for multiple programs each for one application of 
each portable data processing unit. 

35 Moreover, the present invention is directed to 

the provision of the use of access condition ver- 
ifications not prescribed by the manufacturer of the 
portable processing unit but chosen by the applica- 
tion designer to suit his particular needs. 

40 Therefore the system according to the inven- 

tion is characterized in that the memory means 
further comprises at least one interaction context 
containing the following coherent data structure: 

a. a set of basic communication primitives which 
45 are accepted whenever the data processing unit 

communicates with a similar unit, said primitives 
at least including a primitive used to selectively 
enter one of the said interaction contexts; 

b. a set of procedural descriptions defining the 
50 actions to be performed in response to each of 

the accepted communication primitives, at least 
comprising a first procedural description to be 
performed upon activating the interaction con- 
text, and a last procedural description to be 
55 performed immediately before deactivating the 
context; 

c. a, possibly empty, set of data elements either 
permanently stored or computed, which are 



3 



EP 0 666 550 A1 



4 



available for use when procedures as defined in 
the procedural descriptions are performed; 

d. a, possibly empty, set of references to data 
elements, which references are associated to 
the procedural descriptions, said data elements 
are also accessible to possibly further inter- 
action contexts and are available for use when 
procedures as defined in the procedural descrip- 
tions are performed; 

e. a, possibly empty, data list comprising a list 
of references to data elements which are avail- 
able for explicit reference as part of a commu- 
nication primitive to be used by the procedural 
description associated with the communication 
primitive; 

f. a set of access conditions associated to the 
data elements which are referenced in associ- 
ation to the procedural descriptions; 

g. a set of access conditions associated to the 
list of data references in the data list. 

By defining data within the memory means of 
the portable processing unit in such a way the 
processing unit is really organized as a processor, 
i.e. it not only allows logical operations but it per- 
forms processes which may be loaded in the pro- 
cessing unit by persons authorized to do so, e.g. a 
staff member of a bank. By providing procedures 
which may provide arbitrary complex operations in 
response to received commands and providing an 
explicit list of stored data elements which are ad- 
dressable as part of such commands the commu- 
nication bandwidth can be optimally used; resulting 
in a reduced number of commands exchanged. 
With a system according to the invention many 
actual uses of the system will but require the 
exchange of two commands. The only thing that is 
fixed is the structure within the memory means 
which is defined in such a way that several applica- 
tions of the unit may be added in a very efficient 
way, i.e. by using as little additional memory space 
as possible. This is especially of prime importance 
if the unit is a smart card which is severely limited 
as regards available memory space. Besides, the 
structure according to the invention offers all pos- 
sibilities to include security measures in order to 
inhibit unauthorized people from access to pro- 
cesses or data that they are not entitled to use. 

In a first preferred embodiment the data ex- 
change system defined above is characterized in 
that the memory means further comprises at least 
two interaction contexts, at least one application 
description and a memory element storing a refer- 
ence to the interaction context currently being in 
force, each application description comprising: 
a. a data list comprising references to data 
elements, which references may be accessible 
to two or more interaction contexts and may be 
extended by additional data elements; 



b. a further set of access conditions associated 
to said references or to said additional data 
elements and defining restrictions of use. 
By these measures all references to data ele- 
5 ments which are common to different interaction 
contexts are accessible for all those interaction 
contexts, so they only need be stored once saving 
memory space. Also common access conditions to 
said data references are accessible to predeter- 
w mined interaction contexts. Therefore, also these 
common access conditions need only be stored 
once thereby saving memory space and enhancing 
efficiency. 

Each application description may also com- 

75 prise a procedure library comprising units of ex- 
ecutable code which can be used by procedural 
descriptions of each interaction context associated 
to each of said application descriptions. 

Preferably, the processing unit is suitable for at 

20 least two applications with use of little additional 
memory space. To obtain this object the data ex- 
change system according to the invention is char- 
acterized in that the memory means comprises at 
least two application descriptions and units of ex- 

25 ecutable code which can be used by procedural 
descriptions of each interaction context within each 
application description or by each unit of execut- 
able code of each procedure library within each 
application description. 

30 Preferably, the units of executable code in the 

procedure library are enhanced by including a 
specification of the use of their operational param- 
eters into classes relating to attributes pertaining to 
data elements which can be passed as actual value 

35 in a computation, which computation only proceeds 
if the data attributes and parameter classes match. 
This is an efficient way of verification of access 
conditions both on data level and on function level 
for which a very efficient implementation exists. 

40 More reliability of the system is offered if the 

data exchange system according to the invention is 
characterized in that the executive program com- 
prises a reference to a default interaction context 
which is used to initialise the memory element 

45 storing a reference to the interaction context cur- 
rently being in force, in order to carry out a final 
action after a detection of an internal inconsistency 
in a recovery to a normal state of operation or 
whenever the executive program is active and no 

50 explicit interaction context has been specified by a 
communication primitive received from an opposite 
data processing unit. 

In order to enhance the security of data and 
functions within the processing unit the data ex- 

55 change system according to the invention may be 
characterized in that the memory means comprises 
an interaction context dedicated to comprise Per- 
sonal Identification Numbers and that the executive 
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program is arranged to verify Personal Identifica- 
tion Numbers supplied by a user of the data ex- 
change system. 

Advantageously the Personal Identification 
Number management interaction context and the 
default context can be implemented as part of the 
same device holder application. Support of this 
application by most devices with which a device 
according to the invention communicates would 
give the device owner the opportunity to review his 
personal data as stored in the device memory, for 
instance a smart card holder could be allowed to 
modify his PIN at any smart card terminal which 
provides an appropriate user interface. 

Each application description may comprise a 
list of numeric values which is constructed to pro- 
vide identifiers for ail interaction contexts and com- 
prises at least a first numeric value indicating an 
application type, a second numeric value indicating 
a unique identification of the entity providing the 
application, a third numeric value indicating the 
nature of the application description and further 
numbers each uniquely referring to one interaction 
context associated with the application description. 

The string of numeric values uniquely referring 
to an interaction context provides a means of es- 
tablishing interoperability between two communi- 
cating devices which is more efficient than is cur- 
rently envisaged for e.g. smart cards in relegating 
to the application providing entity the responsibility 
to assign unique values to each interaction context 
while leaving assignment of unique numbers to 
entities and application to relevant bodies of sec- 
toral and international co-operation respectively. 
With benefit the application providing entity can 
assign the unique context numbers to incorporate 
implementation version and secret key generation 
information. 

The data communication means may be ar- 
ranged to structure data exchange in blocks of data 
comprising at least two parts, a first part being data 
qualified as operational in that it is used to influ- 
ence the nature of the operations performed by a 
command as indicated by a communication primi- 
tive or to influence the nature of data resulting from 
operations carried out, a second part being quali- 
fied as security in that it is used to determine the 
appropriateness of performing an operation or of 
the acceptability of data within the operational part, 
to be used in the operation or to prove completion 
of the operation or correctness of the resulting 
data. 

Such appropriateness, acceptability, proof and 
correctness being obtained by performing relevant 
cryptographic operations on the data. Authentica- 
tion and data protection are thus made an integral 
part of the command execution providing better 
security than obtainable in current systems e.g. 



smart cards. 

The executive program may be arranged to 
perform, upon accepting a communication primitive 
to perform operations specified in the current inter- 

5 action context, each operation as part of a pre- 
determined and fixed sequence of actions each of 
which is specified separately as part of a proce- 
dural description associated to the accepted com- 
munication primitive, which actions comprise at 

70 least the following actions: 

a. authorization of the use of the communication 
primitive; 

b. decryption of operational data or any part of 
it; 

75 c. performing a command with any input data; 

d. encryption of any operational data resulting 
from any operation performed; 

e. computation of a proof of completion of any 
performed action or of correctness of the result- 

20 ing data to be used in security computations. 

Security is further enhanced if the data pro- 
cessing unit generates a random transaction num- 
ber upon initializing data transfer, which serves as 
basis for cryptographic computations. 

25 To provide for a possibility to enter a new 

interaction context if required one communication 
primitive may be assigned a specified value which 
will always be interpreted as a request to enter a 
new interaction context. 

30 In a further preferred embodiment the data 

exchange system according to the invention is 
characterized in that it comprises a further data 
processing unit comprising the same elements as 
the data processing unit as well as an application 

35 programmers interface which consists of program 
code designed to allow additional computer pro- 
grams to be implemented to give users control 
over the sequence of exchanged communication 
primitives or to influence the data transferred in 

40 them or to learn or further process the data re- 
ceived in the exchange. Development of software 
for systems according to the invention will benefit 
from the availability of an application programmers 
interface. 

45 In such a preferred embodiment of the inven- 

tion the primitive used to enter a specified inter- 
action context may comprise numeric values to be 
used in security calculations in subsequent com- 
munications, a first value generated at random by 

so one of the processing units and a second value 
serving to identify said one processing unit. 

To further benefit from the current invention, 
each communication primitive may further be struc- 
tured to consist of two or more numeric values 

55 which enhance the expressive power of the com- 
munication primitive for interpretation by the execu- 
tive program. 
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As a first alternative, each communication 
primitive may be composed of two or more 
numeric values, a first value being used to refer to 
a procedural description of an action associated to 
the communication primitive, a second value being 5 
composed of a fixed number of binary values each 
of which is interpreted by the executive program as 
a reference to a single data element. 

As a second alternative, each communication 
primitive may be composed of two or more w 
numeric values, a first value being used to refer to 
a procedural description of an action associated to 
the communication primitive, a second value being 
used to determine which of the data elements 
available for external reference in an active inter- 15 
action context will be used while performing re- 
sponding actions in such a way that any data 
element is selected if it contains a value that 
matches said second value. 

As a third alternative, each communication 20 
primitive is composed of two or more numeric 
values, a first value being used to refer to a proce- 
dural description of an action associated to the 
communication primitive, a second value being 
composed of a number of binary values which are 25 
assigned specific meanings by the executive pro- 
gram to be used in interpreting data formats in the 
communication primitive and in performing re- 
sponding actions. 

The context mechanism defined above and the 30 
techniques it makes available leads to a wider 
range of smart card use and an approach of smart 
card application development which have a number 
of advantages over the traditional ways. 

First of all, it allows the execution of application 35 
specific program code in a smart card without the 
need to thoroughly examine the code for potential 
threats to the security of data stored for other 
applications. As the access conditions which are 
stored with the data on the card are enforced by 40 
the card operating system without possibility of 
outside interference during execution of application 
code, a multi application card scheme does not 
need a program code vetting authority. Such au- 
thority is the only way to allow a private code 4S 
execution facility in traditional smart cards. By ap- 
proving code for execution on a card a vetting 
authority incurs liabilities with respect to the overall 
system security; it makes the management of multi 
application smart card schemes much more com- so 
plex. The associated complexity and costs make 
application specific code in traditional card 
schemes almost infeasible. With the new technique 
the demand for this facility from smart card ap- 
plication providers which has been there for some 55 
time can be met. 

Secondly, as direct consequence of protected 
application of specific programs in cards, a specific 



application can be implemented that is dedicated 
to load other applications in the card. In this way, 
the applications once loaded in a card can be 
protected from the very application that loaded 
them. This protection gives parties involved in a 
multi application card scheme especially the card 
issuing entity and the application providing entities 
a basis for their business agreement. Being based 
on tangible things as the amount of storage needed 
on each card, the number of cards to be equipped 
and the duration of the application on the card 
instead of an abstract notion of "trust" and "good 
care" the application providers contract is easier to 
formulate than in traditionally implemented smart 
cards. Moreover, the card issuer and application 
provider do not need to share secret keys and 
protect this sharing with contractual obligations and 
mutually agreed key transportation facilities. 

Thirdly, the application software if implemented 
based on the new technique has several benefits 
compared with prior art smart card operating sys- 
tems: 

* A minimal exchange of data between a termi- 
nal and a card is needed to establish in- 
teroperability between card and terminal, e.g. 
they support the same application(s). Values 
of data to be exchanged to this end can be 
structured as proposed in the draft interna- 
tional standard ISO 7816-5; 

* To complete a transaction between card and 
terminal the minimal number of data ex- 
changes as theoretically inferred can actually 
be used, because the transaction is com- 
pleted as a private computation, instead of 
the necessity to use a lengthy sequence of 
standard commands; 

* It allows controlled access to data without 
requiring an involved access path dictated by 
a directory and file hierarchy shared by all 
applications as currently in use and proposed 
for standardisation; 

* It allows the development of the terminal and 
smart card application in tandem, which de- 
velopment process can be supported with 
computer software tools such as compilers 
and emulators. Design and implementation of 
card and terminal software can thus be lifted 
above the tedious and error prone assembly 
language coding currently required; 

* It allows standardization of equipment, both 
cards and terminals, using an abstract formal- 
ism to describe the device capabilities which 
gives flexibility towards future developments, 
such as new features offered by card or 
terminal manufacturers. The standardized ter- 
minal capability could include an API. In con- 
trast current standardization efforts in smart 
cards concentrates on prescribing fixed data 
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contents of messages to provide identification 
values to be interpreted in a way as deter- 
mined by the standard, which leaves little 
room for new developments. 
Finally, with the new technique implementors 
of smart card operating systems are given great 
freedom of designing optimal implementations of 
the card's operating system kernel and terminal 
operating system. Smart card hardware designers 
are given several options to optimize chip silicon 
use with hardware support for basic operation in- 
cluded in the system kernel. Hardware cost reduc- 
tion obtained starting with the specialized design 
defined above can be greater than when based on 
improvements on general purpose single chip com- 
puters. 

The invention will now be described in detail 
with reference to some drawings which show an 
example of the implementation of the general prin- 
ciples of the present invention. 

Figure 1 shows a prior art application design on 
smart cards based on an hierarchically orga- 
nized collection of data elements; 
figure 2 presents a diagram of the communica- 
tion flow between a portable processing unit and 
a similar structured processing unit in a format 
currently accepted as standard; 
figure 3 presents a basic implementation of the 
present invention using the concept of inter- 
action contexts in portable processing units, 
such as smart cards, and card terminals; 
figure 4 presents an example of a practical 
organization of an execution context, highlighting 
different relationships between procedural de- 
scriptions contained in the interaction context 
and data elements and library functions used 
while performing the procedures; 
figure 5 shows an example of a flow diagram of 
program execution control and security context 
switches involved in performing the procedural 
description invoked by a communication primi- 
tive. 

The structure of data and files in prior art 
systems is depicted in figure 1 . Basically there is a 
master file 1 which is connected to several elemen- 
tary files 3 and one or more dedicated files 2. Each 
dedicated file 2 may be connected to one or more 
further dedicated files 2 and to one or more ele- 
mentary files 3. The prior art uses a tree-like hier- 
archy of directories and files. The number of subor- 
dinate levels in the prior art structure is in principle 
unlimited. The terminology used in figure 1 is taken 
from the international proposed ISO standard 7816- 
4. According to the standard format for commu- 
nication flow between a portable data processing 
unit 5 and a similar structured data processing unit 
4, as shown in figure 2, the communication com- 
prises a set of pairs of blocks. The communication 



starts with a reset signal m<f> from the data pro- 
cessing unit 4. Such a reset signal may be outside 
the communication bandwidth such as generated 
by power-on-logic in data processing unit 5. The 

5 portable data processing unit 5 responds with an 
answer to reset (ATR) signal ml possibly followed 
by contents. All subsequent pairs of blocks m2, 
m3, m(n-1), mn consist of blocks headed by a 
communication primitive (e.g. a command) followed 

w by contents. 

Figure 3 shows the internal structure of two 
data processing units according to the invention 
which are communicating with each other by trans- 
mitting and receiving data. The left data processing 

75 unit 4 may be, among others, a terminal and the 
right data processing unit may be, among others, a 
portable data processing unit, e.g. a smart card. 
However, the invention is also applicable to two 
portable data processing units able to commu- 

20 nicate with each other by appropriate communica- 
tion means. 

Each of the data processing units 4, 5 com- 
prises data communication means 7, 14 through 
which structured blocks of data can be exchanged. 

25 Each of the data processing units 4, 5 comprises 
processing means 8, 15, and memory means 9, 16. 
The memory means 9, 16 could be any configura- 
tion of read-only memory (ROM), random access 
memory (RAM) and programmable read-only mem- 

30 ory such as electrically erasable programmable 
read-only memory (EEPROM). 

The memory means 9, 16 comprises an execu- 
tive program 12, 17, here indicated by "MAXOS". 
If the portable data processing unit 5 is suitable for 

35 two or more applications the memory means 9, 16 
comprises two or more application descriptions 13- 
(1) ... 13(n), 18(1) ... 18(n). There are as many 
application descriptions as there are applications of 
the data processing unit concerned. Each applica- 

40 tion description is indicated by "CSA". The second 
application description 13(2), 18(2) has been shown 
on an enlarged scale in figure 3 to allow display of 
the contents of each application description. Each 
application description 13(i), 18(i) comprises at 

45 least one "interaction context" 11(1) ... 11(m), 19(1) 
... 19(m). Each interaction context is indicated by 
"CTA". The first of these interaction contexts 11(1), 
19(1) has been shown on an enlarged scale to 
allow display of their contents. Each interaction 

so context contains: 

- a set of commands specifying the commu- 
nication primitives recognized by the inter- 
action context and referencing appropriate 
procedures specified in a set of procedures; 

55 - a set of data; 

- a set of data references to date residing in 
other interaction contexts if any; 
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- a set of procedures that may be performed 
by the executive program 12, 17; 

- a set of access conditions to the data ele- 
ments; 

- a set of external references referring to data 
elements to be used in commands issued by 
the other data processing unit; 

- optionally, developer specified other lists. 
Finally, the memory means 9, 16 comprises a 

memory element 21, 20 that contains a reference 
to the "current CTA", i.e. the interaction context 
currently in force. 

The intention of several interaction contexts 
within one application description is to provide a 
functional separation in possible interactions be- 
tween the data processing units 4, 5. This is espe- 
cially relevant when the functional separation is 
also a separation in security conditions. An exam- 
ple may be a first interaction between a smart card 
and a terminal to open, for instance, a door and a 
second interaction when programming doors that 
are allowed to be opened. The second interaction 
needs a better security than the first interaction and 
is assigned its own interaction context. To obtain 
access to the interaction context is the first step in 
assuring the security of the operations that may be 
executed within the interaction context. 

Figure 4 shows a practical approach to im- 
plementation of the context mechanism displayed 
as a memory organization model which shows the 
relations between data elements, access conditions 
and procedures. The structure of figure 4 applies 
whenever there are two or more applications of the 
portable data processing unit 5. If there is only one 
application the structure is strongly simplified, as 
will be explained later. In figure 4 the reference 
numbers of the data processing unit 5 are de- 
picted. However, the structure of figure 4 is like- 
wise applicable to the memory means 9 of the data 
processing unit 4. In figure 4 data element descrip- 
tions and procedure descriptions are optimally or- 
ganized to reflect sharing of program code and 
sharing of data between different interaction con- 
texts (CTA's) which make up one application 
(CSA). 

The memory means 16 comprise data ele- 
ments H(1) ... H(7), executable code elements G(1) 
... G(5) which are part of the operating system, and 
application descriptions 18(1), 18(2) (CSA1, CSA2). 
In figure 4, data and code which are internal to the 
operating system are left out. The number of data 
elements, executable code elements and applica- 
tion descriptions as presented in figure 4 is only 
given by way of example: the numbers may vary 
as required in reality. 

Each application description 18(1), 18(2) is 
physically present in the memory means. They 
provide a first bottom layer of abstraction to reflect 



memory use. Each application description 18(1), 
18(2) consists of: 

- a procedure library consisting of units of ex- 
ecutable code F(1) ... F(4) that may refer to 

5 units of executable code of the operating 

system made available for this purpose, as 
indicated by arrows p(1) ... p(5); 

- a list of data elements E(1) ... E(7) to be used 
by procedures within the interaction contexts 

70 19(1) ... 19(2) within the present application 

description 18. This data list comprises data 
access conditions and pointers q(1) ... q(7) to 
storage areas holding data elements; 

- an interaction context list comprising a num- 
75 ber of interaction context descriptions 19(1), 

19(2). 

The number of elements within the procedure 
library, the list of data elements and the interaction 
context list within the application description 18(1) 

20 as shown in figure 4 is for presentation purposes 
only. Of course, the number of elements may vary 
depending on the desired application. 

Interaction contexts 19(1), 19(2) are physically 
present in the memory means storing the applica- 

25 tion description 18(1). Logically, the interaction 
contexts provide a second layer of memory use 
control. The combined control provided by this 
second layer and the application description layer 
gives an effective implementation of an execution 

30 context mechanism for portable data processing 
units, such as smart cards. Each interaction context 
19(1), 19(2) comprises: 

- a list of procedural descriptions C(1) ... C(5). 
These procedure descriptions may refer to 

35 procedural descriptions in the procedure li- 

brary within the application description 18 as 
indicated by example arrows s(1), s(2). Alter- 
natively these procedural descriptions may 
refer to executable code elements G(1) ... G- 

40 (5) provided by the operating system, as in- 

dicated by example arrow t(1). As a further 
alternative these procedural descriptions may 
contain explicit references to any data ele- 
ments which are used by the procedure dur- 

45 ing execution and which are present in the 

data list of the application description 18 con- 
cerned, as indicated by arrows r(1) ... r(6); 

- a data list containing data elements B(1 ) ... B- 
(5) exclusively available for use by the proce- 

50 dures in the interaction context concerned. 

Data elements are represented as references 
to the data list of the application description 
18 concerned with associated access con- 
ditions to adhere to when accessing the ac- 

55 tual data, as indicated by arrows u(1) ... u(5); 

- an external interface list comprising commu- 
nication primitives A(1) ... A(4) which are ac- 
cepted as commands by the interaction con- 
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texts 19(1). 19(2) concerned. Each command 
within a communication primitive refers to a 
member of the procedural descriptions C(1) 
... C(5) of the procedure list within the inter- 
action context concerned, as indicated by 
arrows v(1) ... v(4). The commands when 
issued by the communicating device 4, may 
refer to elements in the data list of the ap- 
plication description by one or more address- 
es following the command. Each command 
may be accompanied by data elements as 
input to the command processing. The num- 
ber of addresses as given here is by example 
only and is determined for each command as 
required in reality. 
Protection of data elements is provided for by 
the provision of access conditions. Any external 
command within a communication primitive A(1) ... 
A(4) can only address data elements referenced in 
the data list of the interaction context 19 con- 
cerned. Access is only allowed if the access con- 
ditions are met. These access conditions specify 
the type of access that is allowed for the com- 
mand; such an access condition may be no ac- 
cess, read-only access, read-and-write access, and 
secret key use. Other access conditions may be 
applied too. For example, the command of commu- 
nication primitive A(1) may have read-only access 
to data element B(2) through reference arrow w(2), 
while the command of communication primitive A- 
(2) has read-and-write access to the same data 
element B(2) through reference arrow w(3). 

Procedural descriptions C(1) ... C(5) can refer 
to data elements in the data list of the application 
description 18 concerned and no others. Again, 
access is only provided if the access condition is 
met. These access conditions also specify the type 
of access that is allowed: for instance, no access, 
read-only access, read-and-write access, and se- 
cret key use. Access conditions for different proce- 
dural descriptions within the same interaction con- 
text 19 may differ for the same application descrip- 
tion data list element E(1) ... E(7), e.g. reference 
arrow r(1) may represent a read-only access con- 
dition, whereas reference arrow r(2) may represent 
a read-and-write access condition. 

Access conditions are checked on the relevant 
level, i.e. application description level or interaction 
context level and only once. An element B(1) ... B- 
(5) of the data list within an interaction context 19- 
(1), 19(2) refers directly by arrow u(1) ... u(5) to the 
pointer of a data element in the data list of the 
application description 18(1) because the access 
conditions are already met in the data list element 
E(1) ... E(7) of the application description 18(1). 
Procedural descriptions C(1) ... C(5) within an inter- 
action context 19(1), 19(2) which refer to data list 
elements within application description 18(1), how- 



ever, have to first meet the access condition asso- 
ciated with the data list elements E(1) ... E(7) within 
the application description 18(1). Any data ele- 
ments or procedural description elements within 
s the data lists of the application description 18(1) 
and its associated interaction contexts 19(1). 19(2) 
cannot be referred to by any other application 
description within the memory means 16. The ex- 
ecutable code which constitutes the procedural de- 

io scription can only address data by indirection via 
the restricted set of data references associated with 
each of the procedural descriptions C(1) ... C(5). 
Using data elements described by B(1) ... B(5) the 
list of references is temporarily extended by the 

75 executive program with references to data element 
as obtained by evaluating addresses which are 
actually specified in the communication message 
accepted as the command associated with the pro- 
cedural description. Thus no other data can be 

20 accessed than explicitly specified, and only observ- 
ing specified conditions of use. In other words, the 
preferred memory reference model of figure 4 as 
regards the application description with its asso- 
ciated interaction contexts provides an exclusive 

25 context for operations within one single application 
of the data processing unit 5. Data elements 1-1(1) ... 
H(7) are stored in the memory means 16 common 
to all applications but contain data for exclusive use 
within the context of application description 18(1), 

30 such exclusivity is guaranteed by the executive 
program in allowing existance of a single pointer to 
each storage location such as q(1) from E(1) to H- 
(2). Only the code elements G(1) ... G(5) may be 
referred to by any of the application descriptions 

35 18(1) ... stored within the memory means 16. 
These last references of other application descrip- 
tion than application description 18(1) to the com- 
mon codes G(1) ... G(5) are not explicitly indicated 
in figure 4. However, any person skilled in the art 

40 can easily extend the structure of figure 4 to two or 
more application descriptions 18(1), 18(2),... . 

After having explained how data elements may 
be protected by the use of access conditions of 
different kinds, now, memory management provi- 

45 sions will be explained. For memory management, 
it is desirable that alterable data (data elements) 
and not alterable data (operating system code) can 
be managed by the operating system separately. 
The memory reference model as shown in figure 4 

so provides a separation of code and data elements 
within the memory means 16 which are referred to 
by pointers q(1) ... q(7), p(1) ... p(5) from the data 
list and the procedure library, respectively, within 
the application description 18 concerned. Data list 

55 elements within each interaction context 19(1), 19- 
(2) only contain references to these pointers and 
no direct references to the codes G(1) ... G(5), and 
the data elements H(1) ... H(7) within the memory 
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means 16. The data list of the application descrip- 
tion 18 concerned provides the level of indirection 
required by the operating system to perform mem- 
ory management. 

Code duplication is avoided by providing com- 
mon code libraries on two levels: "command bod- 
ies" like procedural description C(3) which refer to 
code element F(2) in the procedure library in ap- 
plication description 18(1) in order to share com- 
mon codes among different interaction contexts. 
However, the body of procedural description C(3) 
also refers directly to a code G(3) stored in the 
memory means 16 and provided by the operating 
system. All units of executable code G(1) ... G(5) 
provided by the operating system are implemented 
for efficient execution. 

Fundamentally, the memory structure accord- 
ing to figure 4 is also applicable in situations where 
only one application of the data processing unit 5 
is provided for. In that case the only application 
description 18(1) may even coincide with one inter- 
action context 19(1), which interaction context then 
contains at least the following coherent data struc- 
ture: 

a. a set of basic communication primitives A(1) 
... which are accepted whenever the data pro- 
cessing unit 5 communicates with a similar unit 
4, said primitives at least including a primitive 
used to selectively enter one of the said at least 
one interaction contexts; 

b. a set of procedural descriptions C(1) ... defin- 
ing the actions to be performed in response to 
each of the accepted communication primitives 
A(1) at least comprising a first procedural 
description to be performed upon activating the 
interaction context, and a last procedural de- 
scription to be performed immediately before 
deactivating the context; 

c. a, possibly empty, set of data elements H(1) 
... either permanently stored or computed, which 
are available for use when procedures as de- 
fined in the procedural descriptions C(1) ... are 
performed; 

d. a, possibly empty, set of references to data 
elements, which references are associated to 
the procedural descriptions C(1) said data 
elements are also accessible to possibly further 
interaction contexts and are available for use 
when procedures as defined in the procedural 
descriptions C(1) ... are performed; 

e. a, possibly empty, data list comprising a list 
of references to data elements which are avail- 
able for explicit reference as part of a commu- 
nication primitive to be used by the procedural 
description associated with the communication 
primitive; 

f. a set of access conditions associated to the 
data elements which are referenced in associ- 



ation to the procedural descriptions; 
g. a set of access conditions associated to the 
list of data references B(1) ... in the data list. 
If there is only one application provided for the 
5 data processing unit 5 and there are at least two 
interaction contexts 19(1), 19(2) each application 
description comprises: 

a. a data list comprising references E(1) ... to 
data elements, which references may be acces- 

70 sible to two or more interaction contexts 19(1) ... 
and may be extended by additional data ele- 
ments; 

b. a further set of access conditions associated 
to said references E(1) ... or to said additional 

75 data elements and defining restrictions of use. 

The set of procedural descriptions in each of 
the two or more interaction context descriptions 
also contains an additional last procedural descrip- 
tion to be performed immediately before deactivat- 
20 ing the context. 

Figure 5 represents the flow of control in the 
executive program defined above by "MAXOS" 
(12,17). 

After powering the system the software starts 

25 with processing a reset code in step 30. In step 31 
the kernel operations security level of the data 
processing unit is entered. The access conditions 
describing this level are stored in an unmodifiable 
part of memory, e.g. ROM or hardware logic. In 

30 step 32 the non-volatile memory is checked for 
consistency and any modifications which might 
have been left unfinished by sudden power down, 
e.g. by extraction of a smart card, are cancelled. 
Non-volatile memory consistency check only in- 

35 volves examining state information stored in mem- 
ory and computing check sums. The content of 
memory, if accessed at all, is only used to com- 
pute check sums. Thus, the consistency check is a 
safe operation. The exact nature of the consistency 

40 check facilities depends on details of hardware 
within the data processing unit and non-volatile 
memory modification routines which are to a wide 
extent irrelevant to the specified security architec- 
ture. After the general memory consistency check 

45 the pre-computed levels of the security context 
stored in the memory are verified. Finally, the 
random access memory of the data processing unit 
is initiated. 

In step 33, if the executing environment is thus 
so declared safe, the secure application security level 
of the data processing unit is entered. In this level 
any access to memory pertaining the kernel oper- 
ations is blocked. Access to application data and 
description from this level is exclusively provided 
55 through routines in the kernel which maintain state 
information on ongoing memory operations. 

Upon first entry after reset, in step 34 applica- 
tion data element descriptors are used to check 
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consistency of stored data with th8 descriptor and 
memory is changed if in a state inconsistent with 
the attribute as described. An answer to reset 
(ATR) message is composed from application iden- 
tifiers stored in the application descriptors and 
completed with a transaction number computed to 
be unpredictable by the receiving other data pro- 
cessing unit 4. Internal to the data processing unit 
a terminal command is generated to activate a 
default interaction context. Directly after the ATR 
message is sent to the other data processing unit 4 
this internal context activation command is execut- 
ed to provide an interaction context for subsequent 
commands. The ATR message clearly indicates 
the readiness of the data processing unit 5 to 
accept further commands. The default interaction 
context can be designed as part of a "smart card 
holder application" which is present as one stan- 
dard application in all multi-application smart cards. 
In this specific application context the user, i.e. the 
smart card holder, can review his personal data or 
open any of the other applications on the card. 

In step 35, as result of the context activation 
command, the interaction context (CTA) security 
level is entered for the standard smart card holder 
CTA. 

After an application has been activated com- 
pletely it is ready to receive commands from the 
other data processing unit 4. Further processing 
depends on the command received: a command to 
activate an application is handled different than a 
command which is to be executed. Therefore, in 
step 38. after having established that a commu- 
nication primitive is received in step 36 and is 
established to be acceptable in step 37, it is tested 
whether a new application has to be activated. If 
not, step 39 is entered in which the command is 
checked to determine whether it is allowed and the 
input data can be accepted. These checks are 
performed for a command only if specified in the 
application descriptor. Also a decryption of input 
data may be carried out in step 39. 

If the test succeeds the "data access protec- 
tion level" is entered, step 40. On this level, the 
highest security level, routines may be executed 
which are coded by application providers, step 41. 
Such routines are stored in the application descrip- 
tor and function as an application specific reaction 
to a specific command issued by the other data 
processing unit 4. This security level constrains 
memory access to a subset specifically defined for 
the command being executed. 

After carrying out the command with the sub- 
mitted input data in step 41, the data access pro- 
tection level is left, step 42. 

Output data and (cryptographic) proof of com- 
mand completion is generated in step 43. After 
step 43 the program waits for new communication 



primitives, step 36. 

If no special command routine is defined and 
the command can be executed by procedures con- 
sisting solely of operating system functions the 
s data access protection level (step 40) is not en- 
tered, and the command will be performed on the 
interaction context security level directly as the 
operating system routines are designed not to vio- 
late any data protection. 
w If, in step 38, it is established that no new 

application is to be activated the program proceeds 
with step 44 in which a context de-activation proce- 
dure is performed. In step 45 the current applica- 
tion specific security level is left and, in step 46, 

75 within the security level of the executive program 
"MAXOS" the data accompanying the command 
are checked. 

If the command is allowed by proper authen- 
tication as specified for the requested application a 

20 new application specific CTA security level is en- 
tered, step 47. This level restricts access to data 
pertaining to the newly opened application. 

The data processing unit 5 produces data in 
response to a context activation command by ex- 

25 ecuting an initialization instruction as defined in the 
procedure list, step 48. If such an application pro- 
vider coded routine is present the data access 
protection level is entered in step 49. The context 
activation procedure is performed in step 50. In 

30 step 51 the data access protection level is left and 
the response is communicated to the other data 
processing unit 4 and the data processing unit 4 
itself is ready to receive a new command after step 
43, specified above. 

35 After having described the figures 1 to 5, now 

some general remarks to the data exchange sys- 
tem according to the invention are made. 

The codes in the procedure library within each 
application description 18(1), 18(2) may be en- 

40 hanced by including a specification of the use of 
their operational parameters into classes relating to 
attributes pertaining to data elements which can be 
passed as actual value in a computation, which 
computation only proceeds if the data attributes 

45 and parameter classes match. This provides one 
way to verify access conditions both to data ele- 
ments and to functions. Comparing properly en- 
coded bit maps of data attributes and parameter 
classes respectively may provide an efficient im- 

50 plementation for this additional technique. 

The executive program 12, 17 may comprise a 
reference to an interaction context which is used to 
initialize the current interaction context in the mem- 
ory element 20 storing a reference to the inter- 

55 action context currently being in force. By this 
measure it is possible to carry out a final action 
after a detection of an internal inconsistency in a 
recovery to a normal state of operation or when- 
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ever the executive program 12, 17 is active and no 
explicit interaction context has been specified by a 
communication primitive received from the other 
data processing unit 5. This default interaction con- 
text may well be one such context contained in the 
cardholder application as described above. 

Additionally, the memory means 9, 16 may 
comprise an interaction context 11,19 dedicated to 
comprise personal identification numbers (PIN's) 
and the executive program 12, 17 is arranged to 
verify personal identification numbers supplied by a 
user of the data exchange system. Several such 
personal identification numbers, passwords, may 
be used. One such password may be used to 
protect use of the device in transactions where 
privacy sensitive data can be revealed. A second 
password may be used to protect transactions 
where data representing a value payable by the 
password holder is communicated. A third pass- 
word may be used to protect transactions where 
operations are performed deemed critical to the 
security of the application such as modes of pro- 
tection being called upon as specified within each 
of the interaction contexts 11, 19 that may require 
it. Further passwords may be provided for. This 
PIN management interaction context may well be 
one such context contained in the card-holder ap- 
plication as described above. 

Each application description 13, 18 may com- 
prise a list of numeric values which is constructed 
to provide identifiers for all interaction contexts 1 1 , 
19 and each application description 13, 18 may 
comprise at least a first numeric value indicating an 
application type, a second numeric value indicating 
a unique identification of the entity providing the 
application, a third numeric value indicating the 
nature of the application description 13, 18 and 
further numbers each uniquely referring to one 
interaction context 11, 19. The first two numbers 
may be assigned according to rules well estab- 
lished in the trade, whereas the remaining numbers 
may be chosen by the application providing entity 
as deemed appropriate. Especially it may assign 
numeric values to distinguish between different ver- 
sion of the implementation or to identify the gen- 
eration of the set of cryptographic keys employed 
by the application in its cryptographic computa- 
tions. Additionally, the device may include in the 
answer to reset message a list for each of the 
interaction contexts 11, 19 contained in its memory 
means an identification number composed of the 
unique identification values stored with the inter- 
action context. The first element in the list of inter- 
action context identification numbers may be an 
identification for the default context. 

The data communication means 7, 14 are pref- 
erably arranged to structure data exchange in 
blocks of data. These blocks of data comprise at 



least two parts, a first part being data qualified as 
operational in that it is used to influence the nature 
of the operations performed by a command as 
indicated by a communication primitive or data 

5 resulting from operations carried out. A second part 
will be qualified as security in that it is used to 
determine that appropriateness of performing an 
operation or of the acceptability of data within the 
operational part to be used in the operation or to 

w prove completion of the operation or correctness of 
the revealed data. 

When the data is structured in this way the 
executive program 17 may be arranged to perform, 
upon accepting a communication primitive to per- 

75 form operations specified in the current interaction 
context 20, 21, each operation as part of a pre- 
determined and fixed sequence of actions, each of 
which is specified separately as part of a proce- 
dure description rule associated to the accepted 

20 communication primitive. A first action may be 
specified as a function to authorize the use of the 
communication primitive at this point in the se- 
quence of communications. A second action may 
be specified as a function to decrypt the oper- 

25 ational data or any part of it, whereas a third action 
may be specified as the operational procedure 
proper. A fourth part may be specified to encrypt 
any operational data which results from the oper- 
ations performed and a fifth action may be speci- 

30 tied as a function to compute a proof of completion 
of the performed action or of correctness of the 
resulting data or to be used in security computa- 
tions in the receiving data processing unit. These 
actions are reflected by the flow diagram of figure 

35 5. 

Additionally, the data processing unit 5 may 
include in its answer to reset message a number 
chosen to be unpredictable in value by the receiv- 
ing data processing unit 4, which can serve as the 
40 basis for cryptographic computations. Such a num- 
ber may be designated as the "card transaction 
number". 

There will be provided for one communication 
primitive assigned a specified value which will al- 

45 ways be interpreted as a request to enter a new 
interaction context 11, 19. This communication 
primitive may be designated as the "activation 
command". The data accompanying the activation 
command sufficiently specifies the context to be 

so activated possibly by referring to the identification 
numbers communicated as part of the answer to 
reset message. The actions performed in respond- 
ing to the activation command are firstly described 
by the procedural description contained in the con- 

55 text accepting the primitive designated as for deac- 
tivation and secondly described in the procedural 
description designated for activation contained in 
the context specified as to be entered. 
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Preferably the communication primitive used to 
enter a specified interaction context 11, 19 com- 
prises numeric values to be used in security cal- 
culations in subsequent communications. A first 
random value may be generated by one of the 
processing units 4, 5 and a second value may 
serve to identify that one processing unit. This 
identification might be the result of computations, 
which are such that the resulting value sufficiently 
identifies the device and the state of its memory as 
required by computations or other actions which 
might be done in subsequent exchanges of data in 
the interaction context 11, 19 to be activated. Said 
second value may be designated as "terminal iden- 
tification". 

Additionally, the activation command gives as 
part of the resulting data a numeric value serving to 
identify the particular responding data processing 
unit sufficiently as required by computations or 
other actions which might be done in subsequent 
exchanges of data in the context just being ac- 
tivated, which number may be designated as 
"smart card identification". 

Besides the smart card identification number 
may be computed using cryptographic functions 
from data stored in the data processing unit 5 or 
from the data received as part of the activation 
command in such a way that the number varies in 
unpredictable manner when computed in response 
to activation commands received from initiating de- 
vices with differing terminal identification numbers; 
a smart card identification thus computed can be 
designated as the "smart card pseudonym". More- 
over, before performing the actions described in 
the procedural description of the activation proce- 
dure of a context to be entered the executive 
program may perform a cryptographic computation 
specified as part of the procedural description in 
that context designated to be performed upon ac- 
tivation to determine whether the context may be 
activated. The computations may involve use of the 
smart card transaction identification, terminal trans- 
action identification and terminal identification and 
other values stored in the memory means. 

As an alternative to such specific computations 
supported with specific data in performing com- 
mands, commands with bitfield specification of re- 
ferenced data elements may be used. Then, each 
communication primitive is composed of two or 
more numeric values, a first value being used to 
refer to a procedural description of an action asso- 
ciated to the communication primitive, a second 
value being composed of a fixed number of binary 
values each of which is interpreted by the execu- 
tive program 12, 17 as a reference to a single data 
element. This data element is specified in the list 
of external data references in the interaction con- 
text 11, 19 concerned, each data element in the list 



being specified by the presence of a binary value 
of one of the binary numbers in a corresponding 
position in the list of binary values. This second 
value may be designated as the "operand ad- 
5 dresses". Each of the data elements which are so 
specified are made available by the operating ex- 
ecutive program 12, 17 to be used in the respond- 
ing action in a manner as may be described in the 
procedural description of that action. 

70 As an alternative to specific computations with 
specific date and commands with bitfield specifica- 
tion of referenced data elements a command for- 
mat with data match specification of data elements 
may be applied. In that case, each communication 

75 primitive is composed of two or more numeric 
values, a first value being used to refer to a proce- 
dural description of an action associated to the 
communication primitive, a second value being 
used to determine which of the data elements 

20 available for external reference in an active inter- 
action context 12, 19 will be used while performing 
responding actions in such a way that any data 
element is selected if it contains a value that 
matches said second value. This second value may 

25 be designated as the "operand tag specifier". Addi- 
tionally, the interaction context 11, 19 may contain 
a procedural description indicating in what way an 
operand tag specifier given as part of a command 
is to be compared with data contained in any of the 

30 data elements available for external reference in 
that context, which procedural description is per- 
formed to select the intended data elements before 
the procedural description is performed specifying 
the command actions proper. 

35 As a further alternative a command format with 

bitfield specification of command interpretation 
may be used. Then each communication primitive 
is composed of two or more numeric values, a first 
value being used to refer to a procedural descrip- 

40 tion of an action associated to the communication 
primitive, a second value being composed of a 
number of binary values which are assigned spe- 
cific meaning by the executive program 12, 17 to 
be used in interpreting data formats in the commu- 

45 nication primitive and in performing responding ac- 
tions. Here the second value may be designated as 
"command modifier". The values are recognized 
for their assigned meaning by all units equipped 
with this additional technique. 

50 In case the latter alternative is applied the 

command modifier may include a binary value 
which determines whether a third part of the com- 
mand is to be used as operand address or as 
operand tag specifier. However, the command 

55 modifier may, as an alternative, include a binary 
value which determines whether the operation per- 
formed as response to the command will use data 
as one data element or is composed of a concat- 
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enation of data elements one to be processed in 
conjunction with each data element specified as 
part of the command value using operand ad- 
dresses or the operand tag specifier. Alternatively, 
the command modifier may include a binary value 5 
which determines whether data provided with the 
command is encoded using the tag-length-value 
method to discriminate successive concatenated 
data elements. 

A further option is that the command modifier w 
may include a binary value which determines 
whether performing the action implied by the com- 
mand will actually lead to effective change of data 
stored in the data processing unit 5 (smart card) or 
actually result in data computed by the data pro- 75 
cessing unit 5, or that the command result is data 
reflecting the state of the unit with regard to the 
acceptability of the command, the data accom- 
panying it, the size of the data which could result 
from computations or other sundry attributes. 20 

In short, the new technique introduced above 
especially suitable for implementation in smart 
cards is the concept of a separate execution envi- 
ronment. In this approach the processing means 
and other resources in a computer are shared 25 
between different applications as if the application 
was the only user of the computer. Building on this 
new technique in smart card implementations in 
addition a mechanism is provided to define mul- 
tiple access conditions for data shared by a num- 30 
ber of related applications. A second technique 
supported by the separate execution environments 
and introduced above is the possibility to define 
the functional meaning of commands in each envi- 
ronment to obtain a minimum number of com- 35 
mands in each interaction between two similar data 
processing units 4, 5 within a data exchange sys- 
tem. Finally it is possible with the new technique 
for names referring to stored data elements to be 
assigned within each context separately. The refer- ao 
ence to stored data elements as part of a com- 
mand received from one of the data processing 
units 4, 5 can thus be made very efficient: due to 
the very small number of data elements and small 
number of distinct operations that is used in to- 45 
day's smart card practice in each environment sep- 
arately only a few bits are needed to encode the 
name and instruction space. In a similar fashion 
access conditions, methods of verification thereof 
and cryptographic operations available to that end 50 
in actual smart cards will be very restricted in 
number and they can be expressed very efficiently 
in the two tier hierarchy of interaction context de- 
scriptions 19(1) ... enclosed in application descrip- 
tion 18. 55 



Claims 

1. Data exchange system comprising at least one 
portable data processing unit (5) comprising 
data communication means (14), processing 
means (15) and memory means (16), the later 
comprising an executive program (17) char- 
acterized in that the memory means (16) fur- 
ther comprises at least one interaction context 
(19(1) ... 19(m)) containing the following coher- 
ent data structure: 

a. a set of basic communication primitives 
(A(1) ...) which are accepted whenever the 
data processing unit (5) communicates with 
a similar unit (4), said primitives at least 
including a primitive used to selectively en- 
ter one of the said interaction contexts (19- 
(1) ...); 

b. a set of procedural descriptions (C(1) ...) 
defining the actions to be performed in re- 
sponse to each of the accepted commu- 
nication primitives (A(1) ...), at least com- 
prising a first procedural description to be 
performed upon activating the interaction 
context, and a last procedural description to 
be performed immediately before deactivat- 
ing the context; 

c. a, possibly empty, set of data elements 
(H(1) ...) either permanently stored or com- 
puted, which are available for use when 
procedures as defined in the procedural de- 
scriptions (C(1) ...) are performed; 

d. a, possibly empty, set of references to 
data elements, which references are asso- 
ciated to the procedural descriptions (C(1) 
...), said data elements are also accessible 
to possibly further interaction contexts and 
are available for use when procedures as 
defined in the procedural descriptions (C(1) 
...) are performed; 

e. a, possibly empty, data list comprising a 
list of references (B(1) ...) to data elements 
which are available for explicit reference as 
part of a communication primitive (A(1) ...) 
to be used by the procedural description 
(C(1) ...) associated with the communication 
primitive; 

f. a set of access conditions associated to 
the data elements which are referenced in 
association to the procedural descriptions 
(C(1) ...); 

g. a set of access conditions associated to 
the list of data references (B(1) ...) in the 
data list. 

2. Data exchange system according to claim 1 
characterized in that the memory means (16) 
further comprises at least two interaction con- 
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texts (19(1) ... I9(m)), at least one application 
description (18(1) ....) and a memory element 
(20) storing a reference to the interaction con- 
text currently being in force, each application 
description comprising: 5 

a. a data list comprising references (E(1) ...) 
to data elements, which references may be 
accessible to two or more interaction con- 
texts (19(1) ...) and may be extended by 
additional data elements; w 

b. a further set of access conditions asso- 
ciated to said references (E(1) ...) or to said 
additional data elements and defining re- 
strictions of use. 

75 

3. Data exchange system according to claim 2 
characterized in that each application descrip- 
tion (18(1) ...) also comprises a procedure li- 
brary comprising units of executable code (F- 

(1) ...) which can be used by procedural de- 20 
scriptions (C(1) ...) of each interaction context 
associated to each of said application descrip- 
tions (18(1) ...). 

4. Data exchange system according to claim 2 or 25 
3 characterized in that the memory means 
comprises at least two application descriptions 
(18(1) ....) and units of executable code (G(1) 

...) which can be used by procedural descrip- 
tions (C(1) ...) of each interaction context (19(1) 30 
...) within each application description (18(1) ...) 
or by each unit of executable code (F(1) ...) of 
each procedure library within each application 
description (18(1) ...). 

35 

5. Data exchange system according to any of the 
claims 3 or 4 characterized in that the units of 
executable code in the procedure library are 
enhanced by including a specification of the 

use of their operational parameters into classes 40 
relating to attributes pertaining to data ele- 
ments which can be passed as actual value in 
a computation, which computation only pro- 
ceeds if the data attributes and parameter 
classes match. 45 

6. Data exchange system according to any of the 
claims 2 to 5 characterized in that the execu- 
tive program (17) comprises a reference to a 
default interaction context which is used to so 
initialise the memory element (20) storing a 
reference to the interaction context currently 
being in force, in order to carry out a final 
action after a detection of an internal inconsis- 
tency in a recovery to a normal state of opera- 55 
tion or whenever the executive program (17) is 
active and no explicit interaction context has 
been specified by a communication primitive 



received from an opposite data processing unit 
(4). 

7. Data exchange system according to any of the 
preceding claims characterized in that the 
memory means (16) comprises an interaction 
context dedicated to comprise Personal Iden- 
tification Numbers and that the executive pro- 
gram (17) is arranged to verify Personal Iden- 
tification Numbers supplied by a user of the 
data exchange system. 

8. Data exchange system according to any of the 
claims 2 to 7 characterized in that each ap- 
plication description (18(1) ...) comprises a list 
of numeric values which is constructed to pro- 
vide identifiers for all interaction contexts (19- 
(1) ...) and comprises at least a first numeric 
value indicating an application type, a second 
numeric value indicating a unique identification 
of the entity providing the application, a third 
numeric value indicating the nature of the ap- 
plication description (18(1) ...) and further num- 
bers each uniquely referring to one interaction 
context (19(1) ...) associated with the applica- 
tion description. 

9. Data exchange system according to any of the 
preceding claims characterized in that the data 
communication means (14) is arranged to 
structure data exchange in blocks of data com- 
prising at least two parts, a first part being data 
qualified as operational in that it is used to 
influence the nature of the operations per- 
formed by a command as indicated by a com- 
munication primitive or data resulting from op- 
erations carried out, a second part being quali- 
fied as security in that it is used to determine 
the appropriateness of performing an operation 
or of the acceptability of data within the oper- 
ational part, to be used in the operation or to 
prove completion of the operation or correct- 
ness of the resulting data. 

10. Data exchange system according to claim 9 
characterized in that the executive program 
(17) is arranged to perform, upon accepting a 
communication primitive to perform operations 
specified in the current interaction context (19- 
(1) ...), each operation as part of a predeter- 
mined and fixed sequence of actions each of 
which is specified separately as part of a pro- 
cedural description associated to the accepted 
communication primitive, which actions com- 
prise at least the following actions: 

a. authorization of the use of the commu- 
nication primitive; 
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b. decryption of operational data or any part 
of it; 

c. performing a command with any input 
data; 

d. encryption of any operational data result- 
ing from any operation performed; 

e. computation of a proof of completion of 
any performed action or of correctness of 
the resulting data to be used in security 
computations. 

11. Data exchange system according to any of the 
preceding claims characterized in that the data 
processing unit (5) generates a random trans- 
action number upon initializing data transfer, 
which serves as basis for cryptographic com- 
putations. 

12. Data exchange system according to any of the 
preceding claims characterized in that one 
communication primitive is assigned a speci- 
fied value which will always be interpreted as a 
request to enter a new interaction context (19- 
(1)...). 

13. Data exchange system according to any of the 
preceding claims characterized in that it com- 
prises a further data processing unit (4) com- 
prising the same elements as the data pro- 
cessing unit (4) which might optionally contain 
in its memory an application programmers in- 
terface (10) which consists of program code 
designed to allow additional computer pro- 
grams to be implemented to give users control 
over the sequence of exchanged communica- 
tion primitives or to influence the data trans- 
ferred in them or to learn or further process 
the data received in the exchange. 

14. Data exchange system according to claim 13 
characterized in that the primitive used to enter 
a specified interaction context (19(1) ...) com- 
prises numeric values to be used in security 
calculations in subsequent communications, a 
first random value generated by one of the 
processing units and a second value serving to 
identify said one processing unit. 

15. Data exchange system according to claim 13 
characterized in that each communication 
primitive is composed of two or more numeric 
values, a first value being used to refer to a 
procedural description of an action associated 
to the communication primitive, a second value 
being composed of a fixed number of binary 
values each of which is interpreted by the 
executive program (12; 17) as a reference to a 
single data element. 



16. Data exchange system according to claim 13 
characterized in that each communication 
primitive is composed of two or more numeric 
values, a first value being used to refer to a 

5 procedural description of an action associated 

to the communication primitive, a second value 
being used to determine which of the data 
elements available for external reference in an 
active interaction context (19(1) ...) will be used 

10 while performing responding actions in such a 

way that any data element is selected if it 
contains a value that matches said second 
value. 

75 17. Data exchange system according to claim 13 
characterized in that each communication 
primitive is composed of two or more numeric 
values, a first value being used to refer to a 
procedural description of an action associated 

20 to the communication primitive, a second value 

being composed of a number of binary values 
which are assigned specific meanings by the 
executive program (12, 17) to be used in inter- 
preting data formats in the communication 

25 primitive and in performing responding actions. 
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